defense acquisition university

The Information Technology (IT)

Sources:

• CJCSI 3170. 01H, 10 Jan 2012

• JCIDS Manual, 19 Jan 2012

• Joint Staff, J-8, RMD

Box

A Primer

Patrick Wills

Associate Dean, Executive Programs,
Requirements Management,
and International Acquisition
Defense Systems Management
College

Defense Acquisition University
work: 703-805-4563 cell: 703-615-

IT Box Topics

BAU

• IT Box Background

• Assumptions

• Applicability

• Governance

• Application

• Information Systems Initial Capabilities
Document (IS ICD)

• Follow-On Documents

• IS Requirements/Acquisition Process

• Examples

• Lessons Learned

• Conclusions

)me charts have additional information in notes pages

2

IT Box Background

BAU

• Why implement an IT box?

• Moore's Law:

- “The number of transistors on an
integrated circuit doubles
approximately every 18-24 months."

- The US has been able to leverage
rapidly-evolving IT for decisive military
advantage .

- However, the JCIDS process does not
provide the required flexibility to take
full advantage of evolving commercial
information technology.

• JROCM 008-08

- The JROC wants to ensure the IT
programs have the flexibility to plan
for and incorporate evolving
technology" throughout the program's
lifecycle.

• CJCSI 3170. 01H

>me charts icmnfeto© tD©nee>p&s in JROCM

MEMORANDUM FOR SEE DISTRIBUTION:

Subject: Leveraging Technology Evolution for Information Technology Systems

T^eJROC directs implementation of the attached change to the Joint

' chnology systems have the appropriate flerribility
nd incorporate evolving technology. This change will
• to CJCSI 3170.01F and CJCSM 3170.01C.

of the Joint Chiefs of Staff

DISTRIBUTION:

Under Secretary of Defense for Acquisition, Technology, and Logistics
Under Secretary of Defense for Intelligence
Commander, US Central Command
Commander, US European Command

Commander, US Pacific Command
Commander, US Southern Command
Commander, US Special Operations Command
Commander, US Strategic Command
Commander, US Transportation Command

Assistant Secretary of Defense for Networks and Information Integration
Under Secretary of the Air Force (Space)

Vice Chief of Staff, US Army
Vice Chief of Naval Operations
Vice Chief of Staff, US Air Force
Assistant Commandant of the Marine Corps

3

BAU

)me charts have additional information in notes pages

JROCM 008-08 Detail

Define minimum capability levels
based upon what is achievable with
today's technology, (is icd paragraph 4
and JROC briefing)

Describe process for approving
capability enhancements. Who will
have the authority to manage
requirements? (jroc Briefing)

Describe the plan for delivering
capability (JROC briefing):

- How often will releases of new or
enhanced capability be delivered?

- What is the plan for assessing the
application of new technologies?

- What is the plan for technology
refresh?

Identify the level of effort funding
which will be used for the software
development effort, (is icd paragraph 4
and JROC briefing)

4

Assumptions

BAU

• The acquisition and programming communities
agree that IS development is different from major
weapon systems

- Modify their processes and documentation expectations
accordingly (modifications to DODI 5000.02 in work)

• The test and certification communities can deliver
on more responsive test and certification
processes to enable more rapid delivery of
capabilities

- Necessitates incremental/iterative development and
testing

)me charts h,

Validation authority for managing requirements
can be pushed down to the lowest level to allow
for rapid changes/decisions (currently within JROC

autborttyi tion in notes pages

5

Reasoning for Additional Change

• The current JCIDS process and documents are structured
to support development of major hardware weapon
systems

• JCIDS and documents are not supportive of the rapid
pace of development necessary with IS
systems/capabilities

- Previous JCIDS Manual Enclosure C (IT Box process) was a
good starting point to address a more agile and responsive
process, but requires adjustment - Modified IT Box

• In conjunction with changes in the acquisition process,
the JCIDS process needs to be adapted to meet the
needs of the operational user so that new capabilities
can be delivered rapidly, and adapted as necessitated
by changes in the operational environment

• Desired Outcome - Provide agile and responsive
requirements/ capability needs process to enable rapid
development of IS capabilities

>me charts have additional information in notes pages

6

Applicability of the IT Box

JCIDS Manual, 19 Jan 2012

BAU

• IT box applies to:

IS with software development only

Includes integration onto commercial off-the-shelf hardware
Program costs exceed $15 million

• IT box DOES NOT apply to:

Systems with a developmental cost less than $15 million
Defense business systems

Systems which are an integral part of a weapon or weapon system
which enables weapon capabilities and are considered part of the
weapon system program

• 19 Jan 2012 JCIDS Manual expands on JROCM 000-08 by
implementing the “IS ICD". Provides greater flexibility and
alignment with:

Sec. 804, NDAA 2010 (Develop new approach for delivering IT
capabilities)

Sec. 933, NDAA 2011 (Develop strategy for rapid acquisition of
tools, applications, and other capabilities for cyber warfare)

Planned update to DoDI 5000.02

)me charts have additional information in notes pages 7

Presentation Template

BAU

Requirements Organization &

Key Points :

• Describe the overall

bounds of an IS program ^ apabilitie
in order to reduce return Required

trips to the JROC for
approval of improved
capabilities.

• Provide to FCB/JCB/JROC
as part of the approval

• programs that do not need to develop
Rcf?iC^ 1 Pe s s*^?ems (leveraging COTS/GOTS hardware).

• Once ICD is approved, no need to return to the JROC with
a CDD or CPD, unless the IS ICD results in a MDAP.

Oversight

JROC

Approve

d

IS ICD

$

Hardware

Refresh &

System

Enhancemen

ts &

Integration

Applications &
System Software

Development &

Acquisition

>me charts have additional information in notes pages

8

2AU

Requirements Organization

And Oversight:

Determines schedule/content of
capability releases based upon
collaboration between users and
the program manager

Guidance:

• Name the flag-level body
holding authority over and
governance for requirements

• Identify chair

• Identify represented
organizations, including all
stakeholders. Include the
acquisition community to
provide advice on technical
feasibility, cost and schedule.

)me charts have additional information in notes pages

Governance

Requirements Organization

Oversight

Capability

Required

JROC

Approve 4
d *

IS ICD

$

Hardware

Refresh &

|vstem

Enhancemen

ts &

Integration

Applications &
System Software

Development &

Acouisition

9

Key Performance Parameters (KPP);
ication & System Software Development and Acquisition

Requirements Organization &

Validated Capability

Requirements

And Initial Minimum Levels:

The initial minimum performance
levels required for the entire IS
program. Objective values not
required nor briefed.

Oversight

JROC

Approve

d

IS ICD

$

Applications &
System Software

Development &

Acquisition

Hardware

Refresh &

$vstem

Enhancemen

ts &

Integration

Application and System Software

Development and Acquisition:

• Estimated development and integration costs for the lifetime of

the program.

• Break out costs into annual estimates.

)me charts have additional information in notes pages

10

£AU

Hardware Refresh &
System Enhancements

Requirements Organization &

Oversight

Capability

Required

JROC

Approve

d

IS ICD

$

Applications &
System Software

Development &

Acquisition

Hardware Refresh and System

Enhancements & Integration:

• Estimated sustainment costs over
the life cycle of the program.

• Break out costs into annual
estimates.

)me charts have additional information in notes pages

11

Information System (IS) ICD

BAU

• IS ICDs Implement the "Information Technology (IT) Box" Model

•IS ICDs are Required When the Solution Requires Research and
Development, and Acquisition of Applications with a Projected
Software Development Cost of Over $15 Million

• Not Used for Software Embedded as a Subset of a Capability
Solution Developed IAW Other Validated JCIDS Documents

• IS ICD Applies to:

Commercial off the Shelf (COTS)/Government off the Shelf (GOTS)
software, and associated hardware without modification

Commercial capability solutions with integrated, DoD-specific
performance standards

Additional production or modification of previously developed U.S
and/or Allied or interagency systems or equipment

Development, integration, and acquisition of customized

)me charts h,

"IT Box" model calls for fewer iterations of validating documents through the JCIDS
process by describing the overall IS program in the IS ICD, and delegating
validation of detailed follow-on requirement and solution oversight to a flag-level
organization other than the JROC or JCB.

£AU

Information System (IS)

ICD

•CDDs & CPDs are Not Required as Successor fCoFTET

Documents; Sponsors Have Management Flexibility
for Alternate Documents

•JCIDS Manual Provides Examples of Potential IS ICD
Follow-On Documents (Actual Names, Content, and
Approval TBD by the Delegated Validation
Authority):

Requirements Definition Package (RDP) - identifies KPPs
and non-materiel changes

Capability Drop (CD) - lower level document that specifies
the characteristics of a "widget" or "app" for partial
deployment of the solution

# Business IS are not normally subject to JROC Review - However,
FCBs have visibility of business case documents posted to KM/DS
and if FCB decides the system has "joint equities" can recommend
>me cha rt joint oversight.

JJg^JJequirements Definition Packages (RDPs)

• RDPs are not a JCIDS document

- Created to break down the requirements into deliverable
increments

■ Responsive, nimble, focused - SPEED

• Provides a more detailed definition of one or more
capabilities in the ICD

- Enables detailed design activity

- Enables detailed costing of the requirements

• Formal incorporation into JCIDS will link to the
acquisition and programming processes

• Approved by the delegated Requirements
Management authority

- FO/GO-level body that holds authority over, and provides
governance for requirements

>me charts have additional information in notes pages

14

Capability Drops (CDs)

BAU

• CDs Are Not a JCIDS Document

- Managing delivery of capabilities through more
specifically defined subsets of an RDP

- The details of how to do this are left to the components
and the acquisition process

• The RDP is Further Broken Down into CDs to
Deliver Individual "Widgets" or "Slices” of
Capability

• The Results of the CD Development are Released
Incrementally Through Full Deployment Decisions
as They Are Ready

• Approved by the Delegated Requirements
Management Authority and the Component PM
lead

)me charts have additional information in notes pages

15

BAU

IS Requirements/Acquisition Process

JROC

Approved

is

ICD

<^>

Component

Approved

— ^[rdf^I pfcpj

Specific

implementation
guidance on
document content
and approval process
to be provided by
Component
-X>

I >[cd] >0

->&-

->Tcd] xC>

->jRDpJ— i>TcD]

— >[cdJ-

->0

Acquire Decision

'A

MS B

>♦

-x>

->fcD>-

-x>

Capabilities ICD
Based (NFU
Assessment 1 "

Engineering

Analysis/

Design

Agile
Developme nt - 1

Rapid Delivery

>me charts have additional information in notes pages

O Fielding Decisions

jj^J^equirements/Acquisition Process (con't)

A

MS A/B

Strategic Joint

Guidance Concepts

Capabilities

Based

Assessment

ICD

(NFjj

Engineering

Analysis/

Design

RDP 1
/

Full

Deployment

Decisions

CDJI CDJI CDJI CDJ | CDJICPJI CDj| CDj| CDj

Agile A 'I' ^ ^ ^ ^ R^qid/QelXer^

beveTo'^O-O-6'OO O O OW^ O

• This shows a very streamlined process for truly
agile IS development

- The ICD is developed in a new format tailored to IS
capabilities

- Following the MDD, one or more RDPs are developed to
further refine the requirements for the needed
capabilities

- The RDP is further broken down into CDs to deliver
individual "widgets" of capability

- The results of the CD development are released
incrementally through Full Deployment Decisions

charts have aaditionaF information in -notes pages 1 J

Execution of the IT Box Process

BAU

• Execution will vary depending on whether this is a
new set of capabilities or whether capabilities are
being added to an existing IS capability set

• A new set of capabilities is initiated through a new IS
ICD

• Adding capabilities to an existing system may enter
at any stage along the process

- In many cases, an update to an existing RDP is all that is
required

- A major expansion of capabilities may require a new IS ICD

• Modifying or enhancing existing capabilities should
only require a mod or a new CD to document what is
needed

- There may be cases where the mod or enhancement has
impact on the architectures or data and this will require a

>me charts have additional informatiaruji-ootes pages. . , . , ,

m r\ H f rv fhn DnO rr\ -rriNw H An i mnnf fhn

Net-Ready KPP Exam

Attribute 1. Support to Military Operai

BAU

NR-KPP

Attribut

e

Key Performance
Parameter

Threshold

Objective

Support

to

military

operation

s

Mission: Tracking and
locating (Finding,

Fixing, Finishing) High-
Value Target (HVT)

Measure: Timely,
actionable
dissemination of
acquisition data for

HVT

Conditions: Targeting
quality data to the
neutralizing/ tracking
entity

10 minutes

Area denial
of HVT
activities

Near-real-time

HVT tracked,
neutralized

Mission Activities: Find

HVT

100 meter
rirrlp

25 meter circle

)me charts hav

Measure: Location

Net-Ready KPP Exan

Attribute 2. Enter and Be Managed in the Ne

BAU

NR-KPP

Key Performance

Thresho

Objecti

Attribute

Parameter

Id

ve

Enter and

Network: SIPRNET

be managed

Measure: Time to

2

1

in the
network

connect to an
operational network
from power up

minutes

minute

Conditions: Network
connectivity

99.8

99.9

Network: NIPRNET

Measure: Time to

2

1

connect to an
operational network
from power up

minutes

minute

Conditions: Network
connectivity

99.8

99.9

)me charts have additional information in notes pages

Net-Ready KPP Examp

Attribute 3. Exchange Informat

BAU

NR-KPP

Key Performance

Threshold

Objective

Attribut

e

Parameter

Exchange

Information Element:

informatio

Target Data

10 seconds

5 seconds

n

Measure:

Dissemination of HVT
biographic and physical

Line of Sight
(LOS)

Beyond LOS

data

2 seconds

Measure: Receipt of

HVT data

5 seconds

NSA certified

NSA certified

type 1

Measure: Latency of

type 1

Non-

data

Permissive

permissive

Measure: Strength of
encryption

environment

environment

t£

Conditions:

Tactical/Geopolitical

Example: Integrated Strategic Planning &

Analysis (ISPAN)

Organization & Oversight

Flag-level oversight through ISPAN Reguirements Governing Council (IRGC)

Chair: GS/CD

Members: ESC SPM, USSTRATCOM CIO
GS COS, J2, J3 f J5 f J6
HQJ63, J82, J83

Key Performance

Parameters

KPP #1 - 4: define mission
planning capabilities required
services and critical user
access devices: 0.99
KPP # 5, 7, and 8 - define
material availability/quality of
service performance
KPP #6 Net-Ready requirement Application and Systems

Software Development
• Per year (FY04-20 = $54. 7M (TY)
• Lifecycle cost = $929. 9M (TY)

"Boundaries"
JROC-Approved
ISPAN
Oversight- ASD(NII) •
Execute - AF/PEO ESCf

h ardware Refresh & System

E nhancements & Integration

Per year (FY04-20) = $22. 8M (T
Lifecycle cost = $387. 3M (TY)

2 r FY = $355. 8M average/yr

)me charts have additional information in notes pages

22

IT Box Cost Driver
Quad Chart

Top Cost Drivers

1 . A, % of program cost

2. B, % of program cost

3. C, % of program cost

4. D, % of program cost

5. E, % of program cost

Performance (KPPS & Select KSAs)

KPP 1
KPP 2
KPP 3
KSA 4
KSA 5

15T

i

T

T

IM

N = No capability IM = Initial Minimum O = Objective

Technology Readiness Assessment

Acquisition Program Baseline (APB)

Baseline

Critical

Technologie

s

Critical

Assessment

Est @ Next
Milestone

Technology

A

TRL #

TRL #

Technology

B

TRL #

TRL #

Technology

C

TRL #

TRL #

nH^mVormation in n

TRL #

otes pages

Cost

I

- Life-cycle cost

- Current Est

I

(DAES Report)

Schedule

- IOC or FOC

I

15T

MSf

MSjt

I +15% + 2 &%

T

— +=

+6 mo +1 yr

RS^etEb Aligns with MAIS reporting]
_ Tripwires in Ch 144A ; FY07 NDAA)

AAI I Example JROCM - Consolidated

Afloat Networks & Enterprise Services (CANES)

Delegates change
authority for non-key
performance
parameters to the Navy

Program oversight for
CANES delegated to the
Navy led Information
Technology Management
Council (ITMS)

ITMC may approve
spiral developments as
long a all initial KPPs and
funding constraints are

24

Lessons Learned/
Working Issues

BAU

• Lessons Learned:

• KPPs in IT program CDDs should be briefed with
"Initial Minimums" only vice traditional
Thresholds/Objectives.

• PAUC/APUC don't apply to IT acquisition; use
different metric.

• For incremental acquisition, ensure IT box
describes entire IT program and not just a single

— i ncrement ( i f poss i b l e).

Working Issues:

• Tie-in IT box (requirements piece) with on-gong DOD IT
acquisition reform efforts (directed by FY 2010 NDAA)

>me charts have additional information in notes pages

25

Conclusion

BAU

• The IT box is the right thing to do for IT
programs

- Provides required flexibility for IT program success

- Allows more effective support to the Warfighter

• High-level guidance and agreement

- VCJCS, JROC, DOD CIO

- Supports FY 2010 NDAA:

"The Secretary of Defense shall develop and implement a
new acquisition process for IT systems .... Based on
recommendations for the DSB Task Force on Acquisition of
IT"

• Must continue close coordination to successfully
implement IT box

)me charts have additional information in notes pages

26